Within a computer processing environment, an interrupt, as the name implies, is some event which interrupts normal program execution. That is, programs execute on a microprocessor sequentially, being altered only by those instructions which expressly cause program flow to deviate in some way (e.g., jump instructions, branch instructions, etc.) Interrupts, on the other hand, give system designers a mechanism to “put on hold” normal program flow, for the purpose of executing a special program called an interrupt handler, and then allows the processor to resume normal program flow as if it had never been interrupted. The interrupt handler is only executed when a certain event (interrupt) occurs. The event may be a timer overflowing, or a serial port transmitting a character. By providing the ability to interrupt normal program execution, certain events such as those mentioned above are much easier and more efficient to handle than requiring the microprocessor to periodically execute special programs.
Referring to FIG. 1, a block diagram is provided that will help illustrate how interrupts are handled within a prior art processing environment. The environment 100 includes a microprocessor 102, coupled to an interrupt controller 110 and memory 120. The microprocessor contains a core 104 for executing instructions retrieved from the memory 120. In addition, the core 104 produces a number of interrupts 106, including both software interrupts and hardware interrupts (e.g., timer overflow) that must be “handled” by the microprocessor 102, as will be further described below with reference to FIG. 2. The microprocessor 102 further includes a cause register 108 for indicating to the microprocessor 102 the cause or source of an interrupt.
The interrupt controller 110 is coupled to a number of external devices 118 via interrupt lines 116, and to other system interrupts 114. The interrupt controller 110, orders the interrupts 110 to provide them to the microprocessor 102 via interrupt lines 112. One skilled in the art will appreciate that early microprocessors 102 were provided with a preset number of interrupt lines 112 for use by system level designers. However, as the need for interrupts increased, rather than adding additional pins on the microprocessor, interrupt controllers 110 were provided to interface between the increased number of interrupts 114, 116, and the existing interrupt lines 112 on the microprocessor 102.
The microprocessor 102 is connected to the memory 120, to retrieve instructions for execution, as mentioned above, to retrieve information relating to interrupts, such as an interrupt vector table 122, and to retrieve the programs which handle the interrupts 124.
Referring now to FIG. 2, a flow chart 200 is shown that illustrates prior art program flow when an interrupt occurs within the microprocessor 102. Operation of the program flow for handling interrupts will now be described with reference to both FIGS. 1 and 2.
Program execution begins at block 202 and proceeds to block 204.
At block 204, instructions are executed by the microprocessor 102 that are retrieved from memory 120. Flow then proceeds to decision block 206.
At decision block 206, a determination is made by the microprocessor 102 as to whether an interrupt has occurred, either by the core 104, or by the interrupt lines 112. Although not shown, the microprocessor 102 includes logic that detects and latches an interrupt when it occurs, thereby alerting the microprocessor 102 of the interrupt. The state of the latches is typically checked by the microprocessor 102 between every instruction execution. If no interrupt has occurred, flow proceeds back to block 204 where the microprocessor 102 continues to execute instructions. However, if an interrupt occurs, flow proceeds to block 208.
At block 208, the microprocessor 102 ceases execution of the current program instructions, and saves its current state information. This allows the microprocessor 102 to return to its present state after responding to the interrupt. One skilled in the art will appreciate that such state information includes the value in the program counter, the values in the status register, various pointers, etc. Flow then proceeds to block 210.
At block 210, the microprocessor 102 jumps to a special program called an interrupt handler (or exception handler), such as interrupt handler #1 124. Flow then proceeds to block 212.
At block 212, the contents of the general purpose register file (GPR) is saved. That is, in every microprocessor, the GPR provides register space where data is stored, examined, manipulated, etc. Before beginning processing of an interrupt, the GPR must be saved so that the interrupt handler can utilize the register space. This may include only certain registers within the GPR, or all the registers in the GPR. Flow then proceeds to block 214.
At block 214, the interrupt is handled by the particular interrupt handler routine 124 that was jumped to. Flow then proceeds to block 216.
At block 216, the contents of the GPR are restored so that the GPR is in the state that it was in prior to the microprocessor 102 taking the interrupt. Flow then proceeds to block 218.
At block 218, the interrupt handler 124 returns program flow back to block 204 to continue execution of the program that was executing when the interrupt occurred. As part of the return step, the state of the microprocessor is restored.
One skilled in the art will appreciate that the above description of the microprocessor system 100, and the interrupt handling flow chart 200 is very general. That is, the description has ignored more complex aspects of interrupt handling, such as what occurs when multiple interrupts occur at the same time, or when an interrupt occurs during handling of another interrupt, or how multiple interrupts are prioritized, etc. However, the above is sufficient to illustrate that when interrupts occur, normal program flow is stopped, the state of the microprocessor is stored, and the contents of resources within the microprocessor, including the GPR, must be saved away, before handling the interrupt.
For interrupts that do not require immediate processing, the time required to save away the contents of the GPR, such as that described above with reference to block 212, is not critical. Thus, if it takes 20–50 clock cycles, for example, to store away the contents of the GPR, before retrieving data from a floppy disk controller, the delay relating to determining the type of interrupt is inconsequential.
However, in many instances the delay associated with saving away the contents of the GPR (as illustrated in FIG. 2) is unacceptable.
Therefore, what is needed is a mechanism that allows a system designer to handle high priority interrupts, without first having to store away the contents of the GPR.
Moreover, what is needed is a method and apparatus that provides shadow registers for the GPR, to be used for handling interrupts and exceptions.
In addition, what is needed is a method and apparatus for binding particular shadow register sets to particular interrupts, or interrupt vectors, so that particular interrupt routines can “effectively” have their own register set.
And, what is needed is a method and apparatus that allows high priority interrupts to begin utilizing their own dedicated resources as soon as possible, rather than having to wait for system resources to first be saved away.